The EDA industry has made significant progress in developing system-level design tools and languages for functional verification. New languages, such as SystemC and SystemVerilog, allow designers to work at much higher abstraction levels for functional description. But abstraction, while certainly necessary for any system-level design language, is not sufficient.
To truly address system-level design, a language must support representation of performance constraints and composition of heterogeneous models. Rosetta is becoming such a language. In this article, we detail system-level design attributes that Rosetta will eventually sport. The Accellera committee is working on those attributes now.
Much has been made recently of the need to move to the system level in computer-based systems design. But what exactly is the system level, and how does it differ from other design abstractions?
In the classical sense, systems engineering involves bringing together information from multiple design decisions that affect overall system correctness. Said differently, system-level design involves preparing to put together all the pieces, both logical and physical. Systems engineers are responsible for integrating subsystems that cross implementation technologies and engineering domains. Further, they are responsible for managing performance requirements such as energy consumption, heat dissipation, packaging and timing.
Traditionally, systems engineering has been applied to large capital and infrastructure projects, along with the design of overwhelmingly complex products such as aerospace vehicles. We are witnessing a paradigm shift within the design process itself, resulting directly from the growing need to apply system-level concepts in the design, implementation and testing of embedded systems. Much more than simply adding languages and abstractions in front of traditional EDA flows, this paradigm shift requires design engineers to integrate and manage performance requirements throughout the design process.
The recent explosion of available implementation technologies, as well as tight interaction with performance requirements (such as power consumption, latency and cost), has rapidly transformed the typical design process into a complex systems-engineering task. As a result, leaders across the electronics design and EDA communities now recognize the urgent need to develop and integrate new design semantics and techniques into the EDA design flow.
A need exists for defining performance requirements as first-class players in the design process and for integrating those requirements into analysis activities.
But why is this a need? Simply put, designers of modern embedded systems do a good job of delivering the required system functionality during the design process, but they have very little support for delivering all the nonfunctional requirements during the design process.
For example, it is well-known that decisions made at the system level-on partitioning into subsystems, on implementation choices for functions (hardware vs. software) and on embedded-system activity controls-have an overwhelming impact on energy consumption of the resulting system. But the design tools available to support the process are minimal, and they offer no support for power and energy budgeting and partitioning. The only power analysis tools offered operate at either the register transfer level (with serious concerns about modeling accuracy) or gate and transistor level (with serious concerns about run-times).
However, system-level tools cannot operate in a vacuum. If the co-design and energy trade-off activity at the system level is to make sense, it requires a standard notation for capturing system requirements and partitioned constraints to complement the design partitioning that will be done with other notations. Power is just one example of such a requirement; similar statements can be made about the performance, area, cost and all other nonfunctional attributes of embedded systems.
Rosetta was conceived as a standard notation or vehicle to capture, refine, partition and analyze system requirements and constraints, both functional and nonfunctional. It is intended to fill a significant gap in the set of modeling notations available to system designers. To support system-level modeling, Rosetta provides explicit mechanisms for describing and combining descriptions of functional and performance requirements for systems and components. Models are written describing various systems aspects; they are composed horizontally to represent structural designs and vertically to describe multiple views of the same component. Through those capabilities, engineers are provided explicit support for addressing system-level issues within a traditional EDA flow.
How Rosetta works
Rosetta supports system-level design by allowing engineers to write and combine specifications defined using heterogeneous semantics. Much as a general contractor would for a traditional construction project, the systems engineer is required to assess system design in a holistic manner. The engineer must consider all aspects of the design and implementation, weighing trade-offs and assuring that individual design decisions do not conflict with system-level requirements. Plans for individual subsystems must be integrated and information considered from multiple domains.
The basic Rosetta specification unit is a facet that describes a system or component from one engineering perspective. Like an individual blueprint, the facet provides information about a single aspect of the design. Each facet is defined in a manner consistent with its associated specification domain. Components from implementation domains such as analog, digital and microelectromechanical systems are specified using a computational model and vocabulary appropriate for those domains. Assembled horizontally, such components define a system architecture.
Similarly, power consumption, function and timing are specified using vocabularies appropriate for each domain. Assembled vertically, such models define different views of the same component. The key is that each model is defined using mechanisms appropriate for its associated engineering domain.
Each facet is built around a set of definitions that provide a basic specification vocabulary for the facet. Those definitions, called domains, allow each facet to be defined in a manner appropriate for the information being represented. Like a symbol legend for a blueprint, the domain provides vocabulary and semantics appropriate for the specific engineering domain. Rather than use a single semantic basis for all specifications, Rosetta provides a flexible system for defining and reusing the basic semantic models.
After writing domain-specific facet specifications for each important system aspect and component, the systems engineer must assemble isolated models into a coherent, predictive systems model. The facet algebra is Rosetta's facility for assembling the facets into systems models. Model composition operators allow horizontal model composition to define systems from components and allow model conjunction (and disjunction) to define how individual models describing the same component or system should be composed.
To support system-level analysis, interactions define when and how information from one domain affects another. The general contractor understands not only when multiple plans should be considered but also when and how those plans affect each other. Rosetta's interaction constructs define how design semantics are transferred across domains. This important capability supports predictive analysis because it explicitly represents how and when models interact. Relationships between domains-such as between clock speed and power consumption, implementation technology and cost, and analog and digital function-are examples of interactions explicitly represented in the Rosetta domain. As such, Rosetta supports concurrent engineering in the design of computer-based systems.
A powerful concept in Rosetta is that it allows subsystems to be composed that are inconsistent or that interact in inconsistent ways. Further, it allows that inconsistency to be analyzed. Design space exploration requires designers to explore infeasible partitionings and compositions as well as feasible ones and to examine the sensitivity of a solution over many possible variations, including ones that could not be implemented. Rosetta by nature supports such analysis and exploration.
In the EDA design flow, Rosetta acts as a semantic-model integration framework. Rosetta's heterogeneous semantics support integration of information from multiple specification domains. Mixed technologies and mixed specifications should not be modeled using a single underlying semantic. Rosetta's domain construct allows each design facet to use appropriate modeling semantics as dictated by the information being represented and by standard engineering practice. Rosetta lets those models be combined without complicating individual engineering processes. By using Rosetta semantics to define models of computation for existing representation languages, models written in disparate simulation languages can be combined with confidence.
Flow benefits
Both traditional design languages, such as VHDL and Verilog, and such emerging languages as SystemC and SystemVerilog benefit from a Rosetta-based design flow. Such languages provide excellent simulation-based analysis capabilities and support emerging formal analysis techniques. Rosetta adds performance constraints, heterogeneous semantics and system-level modeling.
In addition to models of constraint and system-level requirements, Rosetta can interact with traditional HDLs, such as VHDL and Verilog, and with emerging system-level simulation languages and modeling frameworks, such as SystemC, SystemVerilog (a.k.a. Superlog), Ptolemy II and Metropolis. Because models use their own semantic basis, writing and maintaining system-level requirements models in the context of a Rosetta-based design flow becomes far simpler.
Rosetta's declarative semantics support the definition of system-level constraint models. Most constraints are best represented as declarations of properties rather than as operational code. The Rosetta modeling paradigm is well-suited for their representation. In the Rosetta design flow, constraints are equal players in an integrated design process. Designers understand the impact of decisions as they are made and are allowed to explore multiple implementation paths.
Underlying and enabling those capabilities is Rosetta's formal semantics, which provide unambiguous definitions for models and model composition. Tool developers and engineers can understand precisely what their models mean. At the same time, the Rosetta language provides modeling abstractions that allow most modeling tasks to be completed without requiring deep semantic understanding. The formal semantics are there, if needed, but they need not interfere with ordinary tasks.
Rosetta , of course, is not new. What is new is the Accellera Rosetta Committee's commitment to provide a useful language to system designers.
Work on Rosetta started under the independent System Level Design Language activity in 1996, which was driven by system and semiconductor companies concerned that existing methodologies and languages were insufficient to meet emerging challenges in electronic-product design. SLDL continued through a series of worldwide requirements workshops through 1997. After being adopted by VHDL International in 1998, it became part of the united Accellera language-based standards organization, formed with the merger of Open Verilog International and VHDL International (OVI and VI) in March 2000. It is now a technical subcommittee of Accellera, combining the resources of design and EDA companies for unified industry-standards-based solutions.
Accellera's Rosetta Committee is working to develop a standard definition for the language and a base collection of specification domains. Working with the Accellera Semantics Committee, the Rosetta Committee is helping to define not only a language and set of semantics but also a common methodology for addressing system-level issues in semiconductor system design.
For more information on the Rosetta language, demonstrations and tools, visit the Rosetta home page at www.sldl.org. Visit www.eda.org for information about ongoing work.
The members of the committee include me, as chairman, and members Peter Ashenden of Ashenden Designs Pty., David Barton of EDAptive Computing Inc., Andy Carpenter of Manchester University, Grant Martin of Cadence Berkeley Laboratories, Paul Menchini of Menchini Associates, Roberto Passerone of Cadence Berkeley Laboratories and Steve Schulz of Bops Inc.
---
Perry Alexander, the codesigner of Rosetta, is chairman of Accellera's Rosetta Standards Committee and a professor with the University of Kansas' electrical engineering and computer science department. He received all his degrees, including a PhD in EE, from the U. of Kansas.
http://www.isdmag.com
Copyright © 2002 CMP Media LLC
6/1/02, Issue # 14156, page 20.
